\section{Conclusion}

Our paper posed the general environment of computer forensics
analysis, and introduced \textbf{Lemona}, our solution for a monitoring
architecture relying on open standards and implementations, and aiming
towards the post-mortem investigation of compromised systems.

As we demonstrated with the presentation of \textbf{Lemona}'s
performance and settings, its design allows it to theoretically trace
and record the complete activity at the lowest architectural level of
an operating system, permitting a global review of the system's life,
while managing to impact the system with an acceptable overhead, thus
remaining satisfyingly usable and available.

In the long run, \textbf{Lemona} will not only allow a forensics
investigator to determine how and when an attack occured, but also
offer the possibility to review the compromised or exploited resources
and reconstruct the system based on the fine-grained and exhaustive
records it generates, replaying the compromised system's lifecycle
step by step.


\subsection{Limitations}

\textbf{Lemona}, though designed to be a more complete monitoring
facility than the existing solutions, is of course not
foolproof. These are the various ways that we could think of so far to
circumvent its surveillance, or render it inefficient.

\subsubsection{Break the Pipe or Break the Storage Point}

If the connection between \textbf{Lemona}'s storage point and the
\textbf{Lemona}-enabled monitored host can be severed, then of course
the system will not be able to be recovered from future crashes.

Similarly, an attacker could get control over the storage point, which
mean he or she could not only prevent monitoring of malicious
activities, but also destroy already collected evidence or recovery
data, and erase tracks of its presence.

Possible solutions to this problem reside in the hardening of the
transfer connections and host systems, and maybe also in the use of
multiple storage points and connections. There is however no
completely foolproof solution to this issue, and there will not ever
be one, neither with \textbf{Lemona} or any other system.

\subsubsection{Stuck the Pipe}

If an attacker can somehow manage to block outgoing connections or to
overflow the network's throughput, then he or she may be able to
perform malevolent activities that will not have the time to be
reported to the storage point before the system is brought to an
unrecoverable crash or before he can tamper with \textbf{Lemona}'s
system.

A solution to this issue would be to force the system to attribute the
highest priority to outgoing packets emitted by the \textbf{Lemona}
reporting components. This is technically possible, but we have not
implemented such a feature so far.

This problem can also occur if \textbf{Lemona} is running on a machine
with a very high traffic load, such as a web-server hosting a
corporate or e-commerce website. The combination of the
\textbf{Lemona}'s auditing throughput and the normal server load might
reach the bandwidth limitation, and \textbf{Lemona}'s reporting could
be delayed, thus allowing an attacker to exploit a vulnerability and
crash the system without it showing in the logs.

A correct adjustement to the load-balancing taking into consideration
the web-server's network load theoretically overcomes this problem.

\subsubsection{Break Lemona}

It is actually possible that an attacker, who would succeed in
performing a privilege escalation, might render \textbf{Lemona}
unusable. If combined with one of the previous method, it means the
system will not be monitored anymore. If it is not, then it means we
will still be able to review the attack procedure used by the
attacker, but we will not be able to examine the data that was
compromised once \textbf{Lemona} was taken down. This could be a
problem if an organization needs to assert its losses and their
criticality.

There is no real solution to avoid this. \textbf{Lemona} is enabled on
a host, and if the host can be compromised, so can be the tracing and
reporting modules.


\subsection{Future Work}

There are countless possible improvements to \textbf{Lemona}, three of
which are listed below. It could benefit of numerous other variants,
which are currently being studied.

\subsubsection{IDS/IPS Integration}

Conceptualy, \textbf{Lemona} might as well be used as an
\emph{IPS}/\emph{IDS} or interoperate with one. This would of course
require the dynamic analysis of the monitored information. To have
\textbf{Lemona} act as or collaborate with an \emph{IDS}, it would
require its full tracing/reporting/analysis/response process to be
completed in near real-time. Furthermore, to turn \textbf{Lemona} in
or have it operate with an \emph{IPS}, then it would require this same
process to be \emph{atomic} and \emph{real-time}, as we discussed
earlier in our "related work" section. Both solutions would also
require \textbf{Lemona} to be packaged and/or communicate with a
database of exploits' workflows.

\subsubsection{Improvements to the Static Statistical Analyzer}

There are many methods to analyze traces of a monitored system. The
flow of \emph{system calls} can for instance be compared to a database
of well-known exploits, as stated earlier. We could then use pattern
matching techniques to identify attacks spread over longer
timeframes. Several pattern detection mechanisms would be suitable for
this purpose, though they might not be usable in an \emph{atomic} and
\emph{real-time} scheme to turn \textbf{Lemona} into an
\emph{IPS}. They would however be very useful to reduce the noise in
the traces and analyze brand new vulnerabilities.

The analyzer could also rely on new geometrical analysis
methods. These methods typically imply the representation of the
host's activity as a mathematical curve or geometric form, which can
then be compared to a database of preset forms matching the exploits'
database.

\subsection{Design Decisions}

\textbf{Lemona} is a brand new project and its design is still
morphing, both at the low and high levels of the
architecture. \textbf{Lemona} is not designed for performance at the
moment because of the radical changes it goes through on a regular
basis.

We consider revisiting our design to integrate more dynamic and
generic solutions, that would alleviate both the burden of the
developers to integrate new patches and the amount of complexity
required to set up the system.
